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An apparatus and a method for routing data in a radio data 
communication system having one or more host computers, 
one or more intermediate base stations, and one or more RF 
terminals organizes the intennediate base stations into an 
optimal spaiming-tree network to control the routing of data 
to and from the RF terminals and the host computer effi- 
ciently and dynamically. Commtmication between the host 
computer and the RF terminals is achieved by using the 
network of intermediate base stations to transmit the data. 
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RADIO FREQUENCY LOCAL AREA 
NETWORK 

CROSS-REFERENCE TO RELATED 

APPLICATIONS 5 

The present application is a continuation of U.S. Ser. No. 
07/968,990, filed Oct. 30. 1992, (Attorney Docket Nos. 92 
P 758; DN37882YA) now abandoned which is itself a 
continuation in part of an application of Robert C. Meier, , 
U,S. Ser. No. 07/769,425, filed on Oct. 1, 1991, (Attorney 
Docket Nos. 91 P 668; DN37882) now abandoned (this 
subject matter having been published on Mar. 15, 1994 in 
U.S. Pat. No. 5.295.154 by Robert C. Meier). The applica- 
Uon of U.S. Ser. No. 07/968.990, filed Oct. 30. 1992, 
(Attorney Docket Nos. 92 P 758; DN37882YA) is also a 
continuation in part of a PCT application of Robert C, Meier. 
PCT Ser. No. PCr/US92/08610. filed Oct. 1, 1992 (Attorney 
Docket Nos. 92 P 661; DN37882Y) and designating the 
U.S.. and published as WO 93/07691 on Apr. 15. 1993. 

The entire disclosures of each of these applications 
including the drawings and appendices are incorporated 
herein by reference as if set forth fully in this application. 
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In a typical radio data communication system having one 
or more host computers and multiple RF terminals, com- 
munication between a host computer and an RF terminal is 
provided by one or more base stations. Depending upon the 
application and the operating conditions, a large number of 
these base stations may be required to adequately serve the 
system. For example, a radio data communication system 
installed in a large factory may require dozens of base 
stations in order to cover the entire factory floor. 

In earlier RF (Radio Frequency) data communication 
systems, the base stations were typically connected directly 
to a host computer through multi-dropped connections to an 
Ethernet communication line, lb communicate between an 
RF terminal and a host computer, in such a system, the RF ^ 
terminal sends data to a base station and the base station 
passes the data directiy to the host computer. Communicat- 
ing with a host computer through a base station in this 
manner is commonly known as hopping. These earlier RF 
data conmiunication systems used a singje-hop method of 
communication; 

In order to cover a larger area with an RF data commu- 
nication system and to take advantage of the deregulation of 
the spread-spectrum radio frequencies, later-developed RF 
data communication systems are organized into layers of 50 
base stations. As in earlier RF data communications systems, 
a typical system includes multiple base stations which 
communicate directiy with tiie RF terminals and the host 
computer. In addition, die system also includes intermediate 
stations that conununicate witii the RF terminals, tiie mul- 55 
tiple base stations, and other intermediate stations. In such a 
system, communication from an RF terminal to a host 
computer may be achieved, for example, by having the RF 
terminal send data to an intermediate station, the interme- 
diate station send the data to a base station, and the base 
station send the data directiy to the host computer. Commu- 
nicating with a host computer through more than one station 
is commonly known as a multiple-hop communication sys- 
tem. 

DifBculties often arise in maintaining the integrity of such 65 
multiple-hop RF data conununication systems. The system 
must be able to handle both wireless and hard-wired station 



connections, efficient dynamic routing of data information, 
RF terminal mobility, and interference from many different 
sources, 

SUMMARY OF THE INVENTION 

The present invention solves many of the problems inher- 
ent in a multiple-hop data communication system. The 
present invention comprises an RF Local-Area Network 
capable of efGcient and dynamic handling of data by routing 
conmiunications between tiie RF Terminals and tiie host 
computer through a network of intermediate base stations. 

In one embodiment of die present invention, the RF data 
communication system contains one or more host computers 
and multiple gateways, bridges, and RF terminals. Gateways 
are used to pass messages to and from a host computer and 
the RF Network. A host port is used to provide a link 
between tiie gateway and die host computer. In addition, 
gateways may include bridging functions and may pass 
information from one RF terminal to another. Bridges are 
intermediate relay nodes which repeat data messages. 
Bridges can repeat data to and from bridges, gateways and 
RF terminals and are used to extend tiae range of tiic 
gateways. 

The RF terminals are attached logically to the host 
computer and use a network formed by a gateway and the 
bridges to communicate with the host computer. To set up 
the network, an optimal configuration for conducting net- 
work communication spanning tree is created to control the 
flow of data communication. To aid understanding by pro- 
viding a more visual description, this configuration is 
referred to hereafter as a "spanning tree" or "optimal span- 
ning tree". 

Specifically, root of the spanning tree are the gateways; 
the branches are the bridges; and non-bridging stations, such 
as RF terminals, are the leaves of the tree. Data are sent 
along the branches of the newly created optimal spanning 
tree. Nodes in the network use a backward learning tech- 
nique to route packets along the correct branches. 

One object of tiic present invention is to route data 
efiBcienUy, dynamicaliy, and without looping. Anotiier object 
of the present invention is to make the routing of the data 
transparent to the RF terminals. The RF terminals, transmit- 
ting data intended for the host computer, are unaffected by 
die means ultimately used by tiie RF Network to deliver their 
data. 

It is a fiorther objea of the present invention for the 
network to be capable of handling RF terminal mobility and 
lost nodes witii ntinimal impact on tiie entire RF data 
communication system. 

BRIEF DESCRIPTION OF THE DRAWINGS 

HG. l is a functional block diagram of an RF data 
communication system incorporating the RF local-area net- 
work of the present invention. 

FIG. 2 is a flow diagram illustrating a bridging node's 
construction and maintenance of the spanning tree. 

DETAILED DESCRIPTION OF THE 
INVENTION 

FIG. 1 is a functional block diagram of an RF data 
conununication system. In one embodiment of the present 
invention, the RF data communication system has a host 
computer 10, a network controller 14 and bridges 22 and 24 
attached to a data communication link 16. Also attached to 
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the data communication link 16 is a gateway 20 which acts 
as the root node for the spanning tree of the RF data network 
of the present invention. A bridge 42 is attached to the 
gateway 20 through a hard-wired communication link and 
bridges 40 and 44 arc logically attached to gateway 20 by 
two independent RF links. Additional bridges 46, 48, 50 and 
52 are also connected to the RF Network and are shown in 
the FIG. 1. Note that, although shown separate from the host 
computer 10, the gateway 20 (the spanning tree root node) 
may be part of host computer 10. 

The FIG. 1 further shows RF terminals 100 and 102 
attached to bridge 22 via RF links and RF terminal 104 
attached to bridge 24 via an RF link. Also, RF terminals 106, 
108. 110, 112, 114, 116, 118, and 120 can be seen logically 
attached to the RF Network through their respective RF 
links. The RF terminals in HQ. 1 are representative of 
non-bridging stations. In alternate embodiments of the 
present invention, the RF Network could contain any type of 
device capable of supporting the functions needed to com- 
municate in the RF Network such as hard-wired terminals, 
remote printers, stationary bar code scanners, or the like. 
The RF data communication system, as shown in FIG. 1, 
represents the configuration of the system at a discrete 
moment in lime after the initialization of the system, The RF 
links, as shown, are dynamic and subject to change. For 
example, changes in the structure of the RF data commu- 
nication system can be caused by movement of the RF 
terminals and by interference that affects the RF communi- 
cation links. In the preferred embodiment, the host computer 
10 is an IBM 3090, the network controller 14 is a model 
RC3250 of the Norand Corporation, the data communication 
link 16 is an Ethernet link, the nodes 20, 22, 24, 40. 42, 44, 
46, 48, SO and 52 are intelligent base transceiver units of the 
type RB4000 of the Norand Corporation, and the RF termi- 
nals 100, 102, 104, 106, 108. 110. 112, 114, 116, 118 and 120 
are of type RTllQO of the Norand Corporation. 

The optimal spanning tree, which provides the data path- 
ways throughout the commimication system, is stored and 
maintained by the network as a whole. Each node in the 
network stores and modifies information which specifies 
how local conmiunication tra£5c should flow. Optimal span- 
ning trees assure efSdent, adaptive (dynamic) routing of 
information without looping. 

To initialize the RF data communication system, the 
gateway 20 and the other nodes are organized into an 
optimal sparming tree rooted at the gateway 20. To form the 
optimal sparming tree, in the preferred embodiment the 
gateway 20 is assigned a stams of ATTACHED and all other 
bridges are assigned the status UNATTACHED, The gate- 
way 20 is considered attached to the sparming tree because 50 
it is the root node. Initially, all other bridges are unattached 
and lack a parent in the spanning tree. At this point, the 
attached gateway node 20 periodically broadcasts a specific 
type of polling packet referred to hereafter as *'HELLO 
packets". The HELLO packets can be broadcast using 
known methods of conununicating via radio frequency (RF) 
link or via a direa wire link. In the preferred embodiment of 
the present invention, the RF link is comprised of spread- 
spectrum transmissions using a polling protocol. Although a 
polling protocol is preferred, a carrier-sense multiple-access 
(CSMA), busy-tonCi or any other protocol might also man- 
age the communicatipn traffic on the RF link. 

HELLO packets contain 1) the address of the sender, 2) 
the hopping distance that the sender is from the root, 3) a 
source address, 4) a count of nodes in the subtree which flow 
through that bridge, and 5) a list of system parameters. Each 
node in the network is assigned a unique network service 
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address and a node-type identifier to distinguish between 
different nodes and different node types. The distance of a 
node from the root node is measured in hops times the 
bandwidth of each hop. The gateway root is considered to be 
zero hops away from itself. 

FIG. 2 is a flow diagram illustrating a bridge's participa- 
tion in the construction and maintenance of the spanning 
tree. At a block 201, the bridge begins the local construction 
of the spanning tree upon power-up. Next, at a block 203, the 
bridge enters the UNATTACHED state, listening for 
HELLO packets (also referred to as HELLO messages 
herein) that are broadcast. 

^^st ening-to-the-I^^ ^^ssage s..bHd^ 
wluiEpnodcs arc attac^^^t^tfSp5 ^g^^ |MBf^7 
205, the bridge resporid^to|gife|^^^|^^G^ 

Iwffi ch 

•ATT Aj^Hjrdspjonsblifa'bketi^ k 
/dowf^ wards andjg the.bridge? 

Hie bridge awaits the ATTACH.response packet at a 
block 207, Upon receipt of the ATTACH.response packet, at 
a block 209, the bridge enters an AT TACH EjDLstote.Aere^) 
r^after,'at^blgc^^l^Ug.^ begins jp^qdicaJly^broad; 

aiid beginl fdrwarding OTlr^ying ^ 
^p^]^M3received,^Specifically, between HELLO packet 
"broadcasts, the bridge listens for HELLO, DATA, ATTACH- 
jequest and ATTACH.response packets broadcast by other 
devices in the conmiunication network. Upon receiving such 
a packet, the bridge branches to a block 213. At the block 

213, if the bridge detects that it has become detached from 
the spanning tree the bridge will branch back to the block 
203 to establish attachment. Note that although the illustra- 
tion in FIG. 2 places block 213 immediately after the block 
211, the bridges functionality illustrated in block 213 is 
actually distributed throughout the ilow diagram. 

If at the block 213 detachment has not occurred, at a block 

214, the bridge determines if the received packet is a 
HELLO packet. If so. the bridge analyzes the contents of the 
HELLO packet at a block 215 to determine whether to 
change its attachment point in the spanning tree. In a 
preferred embodiment, the bridge attempts to maintain 
attachment to the spanning tree at the node that is logically 
closest to the root node. 

The logical distance, in a preferred embodiment, is based 
upon the number of hops needed to reach the root node and 
the bandwidth of those hops. The distance the attached node 
is away from the root node is found in the second field of the 
HELLO message that is broadcast. In another embodiment 
of the present invention, the bridges consider the number of 
nodes attached to the attached node as well as the logical 
distance of the attached node from the root node. If an 
attached node is overloaded with other attached nodes, the 
unattached bridge may request attachment to the less loaded 
node, or to a more loaded node as described above in 
networks having regions of substantial RF overlap. In yet 
another embodiment, to avoid instability in the spanning 
tree, the bridge would only conclude to change attachment 
if the logical distance of the potential replacement is greater 
than a threshold value. 

If no change in attachment is concluded, at a block 217 the 
bridge branches back to the block 211. If a determination is 
made to change attachment, a DETACH packet is sent to the 
root as illustrated at a block 219. After sending the DETACH 
packet, the bridge branches back to the block 205 to attach 
to the new spanning tree node. Note that the order of shown 
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for detachment and attachment is only illustrative and can be 
reversed. 

Referring back to the block 214, if the received packet (at 
block 211) is not a HELLO packet, the bridge branches to a 
block 221 to forward the received packet through the 
spanning tree. Afterwards, the bridge branches back to the 
block 211 to continue the process. 

Specifically, ^once attachedT the attached bridge^b^ins 
brofdepting HELLO^pa^^ (at-the'block 211) seeking'^to 
have ail unattached bfidgK^oroW network devices) attach 
J;o_th^c_attached bridge, Uponieceiying.an^i^^ 
/ packet, the bndge^fOTwards that.packettoward the root ^n^ 
'^(through the blocks 211, 213, 214 and 2 21. Ojo^its^path 
toward the root, each nodejecords dieyncc^s^ 
of how to reach requesti^ bridgerfhis process is called 
**backward learning" herein, and is discussed more fully 
below. As a result of the backward learning, once the root 
node receives the ATTACH.request packet, an ATTACH- 
xesponse packet can be sent through the spanning tree to the 
bridge requesting attachment. 

After attaching to an attached node, the newly attached 
bridge (the child) must determine its distance from the root 
node. To arrive at the distance of the child from the root 
node, the child adds the broadcast distance of its parent from 
the root node to the distance of the child from its parent. In 
the preferred embodiment, the distance of a child from its 
parent is based on the bandwidth of the data communication 
link. For example, if the child attaches to its parent via a 
hard- wired link (data rate 26,000 baud), then the distance of 
that communication link might equal, for example, one hop. 
However, if the child attaches to its parent via an RF liiik 
(data rate 9600 baud), then the distance of that communi- 
cation link might correspondingly be equal 3 hops. The 
number of the hop corresponds directly to the communica- 
tion speed of the link. This may not only take into consid- 
eration baud rate, but also such factors as channel interfer- 
ence. 

Initially, only the root gateway node 20 is broadcasting 
HELLO messages and only nodes 40, 42 and 44 are within 
range of the HELLO messages broadcast by the gateway. 
Therefore, after the listening period has expired, nodes 40, 
42 and 44 request attachment to the gateway node 20. The 
unattached nodes 40, 42, and 44 send ATTACH-request 
packets and the attached gateway node 20 acknowledges the 45 
ArTACH.request packets with local ATTACH.confirm 
packets. The newly attached bridges are assigned the status 
ATTACHED and begin broadcasting their own HELLO 
packets, looking for other unattached bridges. Again, the 
remaining unattached nodes attempt to attach to the attached 
nodes that are logically closest to the root node. For 
example, node 48 is within range of HELLO messages from 
both nodes 40 and 42. However, node 40 is three hops, via 
an RF link, away from the gateway root node 20 and node 
42 is only one hop, via a hard-wired link, away fr^m the 
gateway root node 20. Therefore, node 48 attaches to node 
42, the closest node to the gateway root node 20. 

The sending of HELLO messages, ATTACH.request 
packets and ATTACH.confirmpackets continues until the 
entire spanning tree is established. In addition, attached 
bridges may also respond to HELLO messages. If a HELLO 
message indicates that a much closer route to the root node 
is available, the attached bridge sends a DETACH packet to 
its old parent and an ATTACH.request packet to the closer 
node. To avoid instability in the system and to avoid 
overloadbg any given node, an attached bridge would only 
respond to a HELLO message if the hop count in a HELLO 
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packet is greater than a certain threshold value, CHANGE_ 
THRESHOLD. In the preferred embodiment, the value of 
the CHANGE_THRESHOLD equals 3. In this manner, an 
optimal spanning tree is formed that is capable of transmit- 
ting data without looping. 

Nodes, other than the gateway root node, after acknowl- 
edging an ATTACHjrequest packet from a previously unat- 
tached node, will send the ATTACRrequest packet up the 
branches of the sparming tree to the gateway root node. As 
the ATTACH.request packet is being sent to the gateway 
root node, other nodes attached on the same branch record 
the destination of the newly attached node in their routing 
entry table. When the ATTACH jequest packet reaches the 
gateway root node, the gateway root node returns an end- 
to-end AFTACH-Confirm packet. 

After the spanning tree is initialized, the RF terminals 
listen for periodically broadcasted Hello packets to deter- 
mine which attached nodes are in range. After receiving 
HELLO messages from attached nodes, an RF terminal 
responding to an appropriate poll sends an ATTACH.request 
packet to attach to the node logically closest to the root. For 
example, RF terminal 110 is physically closer to node 44. 
However, node 44 is three hops, via an RF link, away from 
the gateway root node 20 and node 42 is only one hop, via 
a hard-wired link, away from the gateway root node 20. 
Therefore, RF terminal 110, after hearing IffiLLO messages 
from both nodes 42 and 44, anaches to node 42, the closest 
node to the gateway root node 20. Similarly, RF terminal 114 
hears HELLO messages from nodes 48 and 50. Nodes 48 
and 50 are both four hops away from the gateway root node 
20. However, node 48 has two RF terminals 110 and 112 
afready attached to it while node 50 has only one RF 
terminal 116 attached to it. Therefore, RF terminal 114 will 
attach to node 50, the least busy node of equal distance to the 
gateway root node 20. Attaching to the least busy node 
proves to be the most efficient practice when the commu- 
nication system has little overlap in the RF communicadoh 
regions. In another embodiment, however, instead of attach- 
ing to the least busy node of equal distance to the gateway 
root node 20, the attachment is established with the busiest 
node. 

The attached node acknowledges the ATTACH.request 
and sends the ATTACH.request packet to the gateway root 
node. Then, the gateway root node returns an end-to-eiid, 
ATTACH.confirm packet. In this manner, Jh*e7CTi^o|enS^ 



ATTACHf request ftmctions as a jdiscovery packet enabling 
"the.gateway root liode, and^all other nodes along the. same 
branch, to leani" the address of the RF tenninal quickly. JTiis 
process is called backward learning. Nodes learn the> 
50 <^ addresses of terminals:by monitoring the traflSc from termi- 
"^nals to thle root. If a packet arrives fr^ terminal that is not 
contained in the routing table of the node, an entry is^made 
in the routing table/ The entry includes' the terminal address 
and the address of lie'node that sem _ 
35 an entry timer is set for that terminal. The eiitry^imer is used 
-" --t^deteriniiie wlia^ are actively using the^ 

^tached lH^er^ ^deslnaintain entries o^^^\tert2inais 

^ thk^:ag^^^^j3^^^^gip&4 
en^^^^^^^^oe^tpSacM^^ the RF 

^^¥enninal entry is purgecTfrom the rduting^table. 

' ' The RF links among the RF terminals, the bridges, and the 
gateway are often lost. Therefore, a connection-oriented 
data-link service is used to maintain the logical node-to- 
node links. In the absence of network traffic, periodic 
messages are sent and received to ensure the stability of the 
RF link. As a result, the loss of a link is quickly detected and 
.the RF Network can attempt to establish a new RF link 
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before data transmission from the host computer to an RF 
terminal is adversely affected. 

Communication between terminals and the host computer 
is accomplished by using the resulting RF Network. To 
communicate with the host computer, an RF terminal sends 
a data packet in response to a poll from the bridge closest to 
the host computer. Typically, the RF terminal is attached to 
the bridge closest to the host computer. However, RF 
terminals are constantly listening for HELLO and . polling 
messages from other bridges and may attach to, and then 
communicate with, a bridge in the table of bridges that is 
closer to the particular RF terminal. 

Under certain operating conditions, duplicate data packets 
can be transmitted in the RF Network. For example, it is 
possible for an RF terminal to transmit a data packet to its 
attached node, for the node to transmit the acknowledge- 
ment frame, and for the RF terminal not to receive the 
acknowledgement. Under such ch*cumstances, the RF ter- 
minal will retransmit the data. If the duplicate data packet is 
updated into the database of the host computer, the database 
would become corrupt. Therefore, the RF Network of the 
present invention detects duplicate data packets, lb ensure 
data integrity, each set of data transmissions receives a 
sequence number. The sequence numbers are continuously 
incremented, and duplicate sequence numbers are not 
accepted. 

When a bridge receives a data packet from a terminal 
directed to the host computer, the bridge forwards the data 
packet to the parent node on the branch. The parent node 
then forwards the data packet to its parent node. The 
forwarding of the data packet continues until the gateway 
root node receives the data packet and sends it to the host 
computer. Similarly, when a packet arrives at a node from 
the host computer directed to an RF terminal, the node 
checks its routing entry table and forwards the data packet 
to its child node which is along the branch destined for the 
RF terminal. It is not necessary for the nodes along the 
branch containing the RF terminal to know the ultimate 
location of the RF terminal. The forwarding of the data 
packet continues until the data packet reaches the final node 
on the branch, which then forwards the data packet directly 
to the terminal itself. 

Communication is also possible between RF terminals. To 
communicate with another RF terminal, the RF terminal 
sends a data packet to its attached bridge. When the bridge 45 
receives the data packet from a terminal directed to the host 
computer, the bridge checks to see if the destination address 
of the RF terminal is located within its routing table. If it is, 
the bridge simply sends the message to the intended RF 
terminal. If not, the bridge forwards the data packet to its 
parent node. The forwarding of the data packet up the branch 
continues until a common parent between the RF terminals 
is found. Then, the conunon parent (often the gateway node 
itself) sends the data packet to the intended RF terminal via 
the branches of the RF Netwoik. 

During the normal operation of the RF Network, RF 
terminals can become lost or unattached to their attached 
node. If an RF terminal becomes unattached, for whatever 
reason, its routing entry is purged and the RF terminal listens 
for HELLO or polling messages from any attached nodes in 
range. After receiving HELLO or polling messages from 
attached nodes, die RF terminal sends an ATTACH.request 
packet to the attached node closest to the root. That attached 
node acknowledges the ATTACHjcquesi and sends the 
ATTACH.request packet onto the gateway root node. Then, 
the gateway root node returns an end-to-end ATTACH.con- 
firm packet. 
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Bridges can also become lost or unattached during normal 
operations of the RF Network. If a bridge becomes lost or 
unattached, all routing entries containing the bridge are 
purged. Hie bridge then broadcasts a HELLO.request with 
a global bridge destination address. Attached nodes will 
broadcast HELLO packets immediately if they receive an 
ATTACHjequest packet with a global destination address. 
This helps the lost node re-attach. Thtn,- the bridge enters the 
LISTEN state to learn which attached nodes are within 
range. The unattached bridge analyzes the contents of broad- 
cast HELLO messages to determine whether to request 
attachment to the broadcasting node. Again, the bridge 
attempts to attach to the node that is logically closest to the 
root node. After attaching to the closest node, the bridge 
begins broadcasting HELLO messages to solicit ATTACH- 
.requests from other nodes or RF terminals. 

The spread-spectrum system provides a hierarchical radio 
frequency network of on-line terminals for data entry and 
message transfer in a mobile environment. The network is 
characterized by sporadic data trafSc over multiple-hop data 
patiis consisting of RS485 or ethemet wired links and 
single-channel direct sequenced spread spectmm links. The 
network architecture is complicated by moving, hidden, and 
sleeping nodes. The spread spectrum system consists of the 
following types of devices: 

Terminal controller — A gateway which passes messages 
from a host port to the RF network; and which passes 
messages from the network to the host port. The host port 
(directly or indirectly) provides a link between the controller 
and a "host" computer to which the terminals are logically 
attached. 

Base station — An intermediate relay node which is used 
to extend the range of the controller node. Base station-to- 
controller or base station-to-base station links can be wired 
or wireless RF. 

Terminal — Norand RF hand-held terminals, printers, etc. 
In addition, a controller device has a terminal component 

The devices are logically organized as nodes in an (opti- 
mal) spanning tree, with the controller at the root, internal 
nodes in base stations or controllers on branches of the tree, 
and terminal nodes as (possibly mobile) leaves on the tree. 
Like a sink tree, nodes closer to the root of the spanning tree 
are said to be "downstream" from nodes which are fiiirther 
away. Conversely, all nodes are "upstream" from the root. 
Packets are only sent along branches of the spanning tree. 
Nodes in the network use a "BACKWARD LEARNING" 
technique to route packets along the branches of the span- 
ning tree. 

Devices in the spaiming tree are logically categorized as 
one of the following three node types: 

1) Root (or root bridge) — ^A controller device which 
functions as the root bridge of the network spanning 
tree. In the preferred embodiment, the spanning tree has 
a single root node. Initially, all controllers are root 
candidates from which a root node is selected. This 
selection may be based on the hopping distance to the 
host, preset priority, random selection, etc. 

2) Bridge — ^An internal node in the spanning tree which is 
used to "bridge" terminal nodes together into an inter- 
connected network. The root node is also considered a 
bridge and the term "bridge" may be used to refer to all 
non-terminal nodes or all non-terminal nodes except 
the root, depending on the context herein. A bridge 
node consists of a network interface function and a 
routing function. 

3) Terminal — ^leaf node in the spanning tree. A tenninal 
node can be viewed as tiie software entity that termi- 
nates a branch in the spanning tree. 
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A controller device contains a terminal no(ie(s) and a 
bridge node. The bridge node is the root node if the 
controller is functioning as the root bridge. A base station 
contains a bridge node. A terminal device contains a terminal 
node and must have a network interface function. A "bridg- 
ing entity" refers to a bridge node or to the netv^ork interface 
function in a terminal. 

The basic requirements of the system are the following. 

a) Wired or wireless node connections. 

b) Network layer transparency. 

c) Dynamic/automatic network routing configuration. 

d) Terminal mobility. Terminals should be able to move 
about the RF network without losing an end-to-end 
connection. 

e) Ability to accommodate sleeping terminals. 

f) Ability to locate terminals quickly. 

g) Built-in redundancy. Lost nodes should have minimal 
impact on the network, 

h) Physical link independence. The bridging algorithm is 20 
consistent across heterogeneous physical links. 

The software for the spread-spectrum system is function- 
ally layered as follows. 
Medium Access Control (MAC) 

The MAC layer is responsible for providing reliable 25 
transmission between any two nodes in the network (i.e. 
terminal-to-bridge). The MAC has a channel access control 
component and a link control component. The link control 
component facilitates and regulates point-to-point frame 
transfers in the absence of collision detectioa The MAC 30 
channel access control component regulates access to the 
network. Note that herein, the MAC layer is also referred to 
as the Data Link layer. 
Bridging Layer 

The bridging layer, which is also referred to herein as the 35 
network layeTj^^^^sey^l functions as follows. 

L Th^na^i§^^^^^p^;H^||©:p 
nize nodes in the nelw^^'into'^aii optimil sp^a^ tree 
rooted at the root bridge. The spanning tree is used to 
prevent loops in the topology. Interior branches of the 40 
spanning tree are relatively stable (i.e. coritroller and relay 
stations do not move often). Terminals, which are leaves on 
the spanning three, may become unattached, and must be 
reattached, frequently. 

2. The bridging layer routes packets from terminals to the 45 
host, from the host to teiminals, and from terminals to 
terminals along branches of the spanning tree. 

3. The bridging layer provides a service for storing . 
packets for SLEEPING terminals. Packets which cannot be 
delivered immediately can be saved by the bridging entity in 50 
a parent node for one or more HELLO times. 

4. The bridging layer propagates lost node information 
throughout the spanning tree. 

5. The bridging layer maintains the spanning tree links. 

6. The bridging layer distributes network interface 55 
addresses. 

Logical Link Control Layer 

A logical link control layer, also known herein as the 
Transport layo- herein, is responsible for providing reliable 
transmission between any two nodes in the network (i.e., 60 
terminal -to-base station). The data-link layer provides a 
connection-oriented reliable service and a connectionless 
unreliable service. The reliable service detects and discards 
duplicate packets and retransmits lost packets. The unreli- 
able services provides a datagram facility for upper layer 65 
protocols which provide a reliable end-to-end data path. The 
data-link layer provides ISO layer 2 services for terminal- 



to-host application sessions which run on top of an end-to- 
end terminal-to-host transport protocol. However, the data- 
link layer provides transport (ISO layer 4) services for 
sessions contained within the SST network. 
Higher Layers 

For terminal-to-terminal sessions contained within the 
SST network, the data-link layer provides transport layer 
services and no additional network or transport layer is 
required. In this case, the MAC, bridging, and data-link 
layers discussed above can be viewed as a data-link layer, a 
network layer, and a transport layer, respectively. For ter- 
minal-to-host-application sessions, higher ISO layers exist 
on top of the SST data-link layer and must be implemented 
in the terminal and host computer, as required. This docu- 
ment does not define (or restrict) those layers. This docu- 
ment does discuss a fast-connect VMTP-like transport pro- 
tocol which is used for transient internal terminal-to- 
terminal sessions. 

Specifically, a network layer has several functions, as 
follows. 

1) The network layer uses a "hello protocol" to organize 
nodes in the network into an optimal spanning tree rooted at 
the controller. (A spaiming tree is required to prevent loops 
in the topology.) Interior branches of the spanning tree are 
relatively stable (i.e., the controller and base stations do not 
move often). Terminals, which are leaves on the spanning 
tree, become unattached, and must be reattached frequently. 

2) The network layer routes messages from terminals to 
the host, from the host to terminals, and from terminals to 
terminals along branches of the spanning tree. 

3) The network layer provides a service for storing 
messages for SLEEPING terminals. Messages which caimot 
be delivered immediately can be saved by the networic entity 
in a parent node for one or more hello times. 

4) The network \ay&c propagates lost node information 
throughout the spanning tree. 

5) The network layer maintains the spanning tree links in 
the absence of regular data traffic. 

A transport layer is responsible for establishing and 
maintaining a reliable end-to-end data path between trans- 
port access points in any two nodes in the network. The 
Uansport layer provides unreliable, reliable and a transac- 
tion-oriented services. The transport layer should be 
immune to implementation changes in the network layer. 

The responsibilities of the transport layer include the 
following. 

1) Establishing and maintaining TCP-like connections for 
reliable root-to-terminal data transmission. 

2) Maintaining VMTP-like transaction records for reliable 
transient message passing between any two nodes, 

3) Detecting and discarding duplicate packets. 

4) Retransmitting lost packets. 

Layers 1 through 4 are self-contained within the Norand 
B^F network, and are independent of the host computer and 
of terminal applications. The session layer (and any higher 
layers) are dependent on specific applications. Therefore, the 
session protocol (and higher protocols) must be imple- 
mented as required. Note that a single transport access point 
is sufficient to handle single sessions with multiple nodes. 
Multiple concurrent sessions between any two nodes could 
be handled with a session identifier in a session header. 

Network address requirements are as follows. DLC 
framed contain a hop destination and source address in the 
DLC header, network packets contain an end-to-end desti- 
nation and a source address in the network header, TYansport 
messages do not contain an address field; instead, a transport 
connection is defined by network layer source and destina- 
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tion address pairs. Multiple transport connections require 
multiple network address pairs. 

The transport header contains a TRANSPORT ACCESS 
POINT identifier. DLC and network addresses are consistent 
and have the same format. Eacti node has a unique LONG 5 
ADDRESS which is programmed into the node at the 
factory. The long address is used only to obtain a SHORT 
ADDRESS from the root node. 

The network entity in each node obtains a SHORT 
ADDRESS from the root node, which identifies the node 
uniquely. The network entity passes the short address to the 
DLC entity. Short addresses are used to minimize packet 
sizes. 

Short addresses consist of the following. There is: 

an address length bit (short or long). 

a sparming tree identified. 

a node-type identifier. Node types are well knowa 

a unique multi-cast or broadcast node identifier. 

The node-identifier parts of root addresses are well known 
and are constant. A default spanning tree identifier is well 20 
known by all nodes. A non-default spanning tree identifier 
can be entered into the root node (i.e., by a network 
administrator) and advertised to all other nodes in *'hello" 
packets. The list of non-default spanning trees to which 
other nodes can attach must be entered into each node. 25 

A node-type identifier of all I's is used to specify all node 
types. A node identifier of all Ts is used to specify all nodes 
of the specified type. A DLC identifier of all O's is used to 
specify a DLC entity which does not yet have an address. 
The aU-O's address is used in DLC frames that are used to 30 
send and receive network ADDRESS packets. (The network 
entity in each node filters ADDRESS packets based on the 
network address.) 

Short-address allocation is accomplished as follows. 
Short node identifiers of root nodes are well known. All 35 
other nodes must obtain a short node identifier from the rooL 
To obtain a short address, a node send an ADDRESS request 
packet to the root node. The source addresses (i.e., DLC and 
network) in the request packet are LONG ADDRESSES. 
The root maintains an address queue of used and unused 40 
SHORT ADDRESSES. If possible, the root selects an avail- 
able short address, associates the short address with the long - 
address of the requesting node, and returns the short address 
to the requesting node in an ADDRESS acknowledge 
packet (Note that the destination address in the acknowl- 45 
edge packet is a long address.) 

A node must obtain a (new) short address initially and 
whenever an ADDRESS-TIMEOUT inactivity period 
expires without having the node receive a packet from the 
network entity in the root. 50 

The network entity in the root maintains addresses in the 
address queue in least recently used order. Whenever a 
packet is received, the source address is moved to the end of 
the queue. The address at the head of the queue is available 
for use by a requesting node if it has never been used or if 55 
it has been inactive for a MAX-ADDRESS-LIFE time 
period. 

MAX-ADDRESS-LIFE must be larger than ADDRESS- 
TIMEOUT to ensure that an address is not in use by any 
node when it becomes available for another node. If the root 60 
receives an ADDRESS request from a source for which an 
entry exists in the address queue, the root simply updates the 
queue and returns the old address. 

The network layer organizes nodes into an optimal span- 
ning tree with the controller at the root of the tree. (Note that 65 
the spanning three identifier allows two logical trees to exist 
in the same coverage area.) Sparming tree organization is 
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facilitated with a HELLO protocol which allows nodes to 
determine the shortest path to the root before attaching to the 
spanning tree. All messages are routed along branches of the 
spanning tree. 

Nodes in the network are generally categorized as 
ATTACHED or UNATTACHED. Initially, only the root 
node is attached. A single controller may be designated as 
the root, or multiple root candidates (i.e. controllers) may 
negotiate to determine which node is the root. Attached 
bridge nodes and root candidates transmit "HELLO** packets 
at calculated intervals. The HELLO packets include: 

a) the source address, which includes the spanning tree 
ID). 

b) a broadcast destination address. 

c) a "seed" value from which the time schedule of future 
hello messages can be calculated. 

d) a hello slot displacement time specifying an actual 
variation that will occur in the scheduled arrival of the 
very next hello message (the scheduled arrival being 
calculated from the "seed'*). 

e) the distance (i.e., path cost) of the transmitter from the 
host The incremental portion of the distance between 
a node and its parent is primarily a function of the type 
of physical link (i.e., etheraet, RS485, RF, or the like). 
If a signal-strength indicator is available, connections 
are biased toward the link with the best signal strength. 
The distance component is intended to bias path selec- 
tion toward (i.e., wired) high-speed coimections. Set- 
ting a minimum signal strength threshold helps prevent 
sporadic changes in the network. In addition, connec- 
tions can be biased to balance the load (i.e., the number 
of children) on a parent node. 

f) a pending message list. Pending message lists consist of 
0 or more destination-address/message-length pairs. 
Pending messages for terminals are stored in the ter- 
minal's parent node. 

g) a detached-node list. Detached-node lists contain the 
addresses of nodes which have detached from the 
spanning tree. The root maintains two lists. A private 
list consists of all detached node addresses, and an 
advertised list consists of the addresses of all detached 
nodes which have pending transport messages. The 
addresses in the hello packet are equivalent to the 
advertised list. 

An internal node learns which entries should be in its list 
from hello messages transmitted by its parent node. The root 
node builds its detached-node lists from informadon 
received in DETACH packets. Entries are included in hello 
messages for DETACH-MSG-UFE hello times. 

Attached notes broadcast "SHORT HELLO" messages 
inunediately if they receive an "HELLO.request" packet 
with a global destination address; otherwise, attached nodes 
will only broadcast hello messages at calculated time inter- 
vals in "hello slots." Short hello messages do not contain a 
pending-message or detached-node list. Short hello mes- 
sages arc sent independently of regular hello messages and 
do not affect regular hello timing. 

Unattached nodes (nodes without a parent in the spanning 
tree) are, initially, in an "UNATTACHED LISTEN" state. 
During the listen state, a node learns which attached base 
station/controller is closest to the root node by listening to 
hello messages. After the listening period expires an unat- 
tached node sends an ATTACH.request packet to the 
attached node closest to the root. The attached node imme- 
diately acknowledges the ATTACILrequest, and send the 
ATTACH.request packet onto the root (controller) node. The 
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root node returns the request as an end-to-end ATTACH- 
.confirm packet If the newly-attached node is a base station, 
the node calculates its link distance and adds the distance to 
the distance of its parent before beginning to transmit hello 
messages. 

The end-to-end ATTACH.request functions as a discovery 
packet, and enables the root node to learn the address of the 
source node quickly. The end-to-end ATTACHjequest, 
when sent from a node to the root, does not always travel the 
entire distance. When a downstream node receives an 
ATTACH-request packet and already has a correct routing 
entry for the associated node, the downstream node inter- 
cepts the request and returns the ATTACH.confinn to the 
source node. (Note that any data piggy-backed on the 
ArrACH.request packet must still be forwarded to the host.) 
ITiis situation occurs whenever a '*new" path has more than 
one node in common with the "old" path. 

The LISTEN state ends after MIN_HELLO hello time 
slots if hcUo messages have been received from at least one 
node. If no hello messages have been received the listening 20 
node waits and retries later. 

An attached node may respond to a hello message from a 
node other than its parent (i.e., with an ATTACH.request) if 
the difference in the hop count specified in the hello packet 
exceeds a CHANGE-THRESHOLD level. 

Unattached nodes may broadcast a GLOBAL ATTACH- 
jequest with a multi-cast base station destination address to 
solicit short hello messages from attached base stations. The 
net effect is that the LISTEN state may (optionally) be 
shortened. (Note that only attached base station or the 
controller may respond to ATTACH, requests.) Normally, 
this facility is reserved for base stations with children and 
terminals with transactions in progress. " ] 

^AITACH. requests contain. a .(possibly .empty) CHILD 
LIST, to enable intemal>^n3S^^tp update.thcir jrgpringiables. 35 
ArTACH.requests also contain a "count" fieTTwfich indi- 
cates that a terminal may be SLEEPING. The network entity 
in the parent of a SLEEPING terminal con temporarily store 
messages for later delivery. If the count fieldis non-zero, the 
network entity mAR ^i|^^^ 40 
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have expired! 

Transport layer data can be piggy-backed on an attached 
request packet from a terminal, (i.e., an attach request/ 
confirm can be implemented with a bit flag in the network 45 
header of a data packet.) 

Network layer routing. , _ 

All messages are routed along branches of the spaiming 
gjee3|^e stations4g^ni"v.the ai^ress-of 'teraunalf-b^ 
monitoring^ traffic ft^^^r&ljg;e.|%^M^^^ 50 

fh^ station receives (ie^^ AITACH.5pVcst) packet, 
destined fom'e r6o|tith^^ an 

' en^^^ifrits^ ThQ eiitry includes 

rilthe-termin^ addiess, and the addi;c!ss^of tlie iDase station 
w]KcirsCTt..th'e'p^ (he;fathe hop^address). When a base 55 
station receives an^ upstream packeti¥'(i^f:i*iBr6m the root, 
destined j^ajtenninalj^e^^ is simply forwacded to the> 

, rba3c^stStibn'%hite5'?ii^^ entry for the destination. 

^ Upstream messages (i.e., to a terminal) are discarded when- 
ever a routing entry does not exist. Downstream messages 60 
(i.e., from a terminal to the root) are simply forwarded to the 
next downstream node (i.e., the parent in the branch of the 
spanning tree. 

TERMINAL-TO-TERMINAL COMMUNICATIONS is 
accomplished by routing all terminal-to-terminal traffic 65 
through the nearest common ancestor. In the worst case, the 
root is, the nearest conunon ancestor. A "ADDRESS 



SERVER" facilitates tcrminal-to-tcrminal communications 

(see below). ^ 

^rDEtBlTNG INVAlS^UflNG TABLE ENTRJES:isr 
accomplished in several ways: cormection oriented transport / 
layer ensures that packets will arrive from nodes attached.toA 
(the , branch of the s panning tree within-thc^timeourperiod; 

unlessanode-is-disconnected.) — ^ 

2) Whenever the DLC entity in a parent fails RETRY 
MAX times to send a message to a child node, the node is 
logically disconnected from the spanning tree, with one 
exception. If the child is a SLEEPING terminal, the message 
is retained by the network entity in the parent for "count" 
hello times. The parent immediately attempts to deliver the 
message after it sends its next hello packet If, after "count" 
hello times, the message cannot be delivered, then tiie child 
is logically detached ftom the spanning tree. Detached node 
information is propagated downstream to the root node, each 
node in the path of the DETACIH packet must adjust its 
routing tables appropriately according to the following rules: 
a) if the lost node is a child terminal node, the routing entry 
for tile terminal is deleted and a DETACH packet is gener- 
ated, b) if the node specified in DETACH packet is a 
terminal and the node which delivered the packet is the next 
hop in the path to the terminal, then the routing table entry 
for the terminal is deleted and the DETACH packet is 
forwaided, c) if the lost node is a child base station node then 
all routing entries which specify that base station as the next 
hop are deleted and a DETACH packet is generated for each 
lost terminal. 

IN GENERAL, WHENEVER A NODE DISCOVERS 
THAT A TERMINAL IS DETACHED, IT PURGES ITS 
ROUTING ENTRY FOR THE TERMINAL. WHENEVER 
A NODE DISCOVERS THAT A BASE STATION IS 
DETACHED, IT PURGES ALL ROUTING ENTRIES 
CONTAINING THE BASE STATION. ONLY ENTRIES 
FOR UPSTKEAM NODES ARE DELETED. 

When DETACH packets reach the root node, tiiey are 
added to a "detached list" Nodes remain in the root node's 
detached list until a) the node reattaches to the spanning tree, 
or b) the list entry times out. The detached list is included in 
hello messages and is propagated throughout the spanning 
tree. 

For example, if a terminal detaches and reattaches to a 
different branch in the spanning tree, all downstream nodes 
in die new branch (quickly) "learn" the new patii to the 
terminal. Nodes which were also in the old path change their 
routing tables and no longer forward packets along the old 
path. At least one node, the root, must be in both the old and 
new path. A new path is established as soon as an end-to-end 
attach request packet from the terminal reaches a node 
which was also in the old path. 

4) A node (quickly) learns that it is detached whenever it 
receives a heUo message, from any node, with its address in 
the associated detached list. The detached node can, option- 
ally, send a global ATTACH.request. and tiien enters the 
UNATTACHED LISTEN state and reattaches as described 
above. After reattaching, the node must remain in a HOLD- 
Down state until its address is aged out of all detached lists. 
During tiie HOLD-DOWN state die node ignores detached 
lists. 

5) A node becomes disconnected and enters the UNAT- 
TACHED LISTEN state whenever HELLO-RETRY-MAX 
hello messages arc missed firom its parent node, 

6) A node enters tiie ATTACHED LISTEN state whenever 
a single hello message, from its parent, is missed. SLEEP- 
ING terminals remain awake during the ATTACHED LIS- 
TEN state. The state ends when the terminal receives a data 
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or hello message from its parent. The terminal becomes 
UNATTACHED when a) its address appears in the detached 
list of a hello message f^om an ode otiier than its parent, or 
b) HELLO-RETRY-MAX hello messages are missed. The 
total number of hello slots spend in the LISTEN state is 
constant 

If a node in the ATTACHED LISTEN state discovers a 
path to the root which is CHANGB-THIiESHOLD shorter, 
it can attach to the shorter path. Periodically, SLEEPING 
terminals must enter the ATTACHED Leam state to discov- 
ery any changes (i.e., shorter paths) in the network topology. 
Hello synchronization. 

All attached non-terminal nodes broadcast periodic 
"heUo" messages in discrete "hello slots" at calculated 
intervals. Base station nodes leam which hello slots are busy 
and refrain from transmitting during busy hello slots. 

A terminal refrains from transmitting during the hello slot 
of its parent node and refrains from transmitting during 
message slots reserved in a hello message. 

The hello message contains a "seed" field used in a 
well-known randomization algorithm to determine the next 20 
hello slot for the transmitting node and the next seed. The 
address of the transmitting node is used as a factor in the 
algorithm to guarantee randomization. Nodes can execute 
the algorithm i times to determine the time (and seed) if the 
i-the hello message from the transmitter. 

After attached, a base station chooses a random initial 
seed and a non-busy hello slot and broadcasts a hello 
message in that slot The base station chooses succeeding 
hello slots by executing the. randomization algorithm. If an 
execution of the algorithm chooses a busy slot, the next free 30 
slot is used and a hello "displacement" field indicates the 
offset from a calculated slot. Cumulative delays are not 
allowed (i.e., contention delays during the i hello transmis- 
sion do not effect the time of the i+1 hello transmission). 

HELLO-TIME and HELLO-SLOT-TIME values are set 35 
by the root node and flooded throughout the network in hello 
messages. The HELLO-SLOT-TIME value must be large 
enough to minimize hello contention. 

A node initially synchronizes on a hello message from its 
parent. A SLEEPING node can power-down with an active 
timer interrupt to wake it just before the next expected hello 
message. The network entity in base station nodes can store 
messages for SLEEPING nodes and transmit them inmie- 
diately following the hello messages. This implementation 
enables SLEEPING terminals to receive unsolicited mes- 
sages. (Note that the network layer always tries to deliver 
messages immediately, before storing them.) Retries for 
pending messages are transmitted in a round-robin order 
when messages are pending for more than one destination. 

Note that a child node that misses i hello messages, can 50 
calculate the time of the i+1 hello message. 
Transport layer theory and implementation notes. 

The transport layer provides reliable, unreliable, and 
transaction-oriented services. Two types of transport con- 
nections are defined: 1 ) a TCP-like transport connection may 55 
be explicitly requested for long-lived connections or 2) a 
VMTP-like connection-record may be implicitly set up for 
transient connections, In addition, a connectionless service 
is provided for nodes which support an end-to-end transport 
connection with the host computer. 

The interfaces to the next upper (Le., application) layer 
include; 

CONNECT (access_point, node_name) 
LISTEN (access_point) 

UNITOATA (access_point. node_name, buffer, length) 
SEND (handle, buffer, lengtii) 



RECEIVE (handle, buffer, length) 
CLOSE (handle) 

The "handle" designates the coimection type, and is the 
connection identifier for TCP-like connections. 

SEND , messages require a response from the network 
node (root or terminal) to which the message is directed. 

UNIXDATA messages do not require a response. UNIT- 
DATA is used to send messages to a host which is capable 
of supporting end-to-end host-to-terminal transport cormec- 
tions. 

Because the network layer provides an unreliable service, 
the transport layer is required to detect duplicate packets and 
retransmit lost packets. Detecting duplicates is facilitated by 
numbering transport packets with unambiguous sequence 
numbers. 

Transport connections. 

TCP-like transport connections are used for message 
transmission over long-lived connections. The coimections 
may be terminal-to-root or terminal-to-terminal (i.e., base 
stations are not involved in the transport connection); 

TCP-like transport coimections are established using a 
3-way handshake. Each end selects its initial sequence 
number and acknowledges the other end's initial sequence 
number during the handshake. The node which initiates the 
connection must wait a MAX PACKET-LIFE time, before 
requesting a connection, to guarantee that initial sequence 
numbers are unambiguous. Sequence numbers arc incre- 
mented modulo MAX-SEQ, where MAX-SEQ is large 
enough to insure that duplicate sequence numbers do not 
exist in die network. Packet types for establishing and 
breaking coimections are defined as in TCP. 

A TCP-like connection is full-duplex and a sliding win- 
dow is used to allow multiple outstanding transport packets. 
An ARQ bit in tiie transport header is used to require an 
immediate acknowledgment from the opposite end. 

VMTP-like connections are used for transient messages 
(i.e. terminal-to-terminal mail messages). VMTP-like con- 
nection records are built automatically. A VMTP-like con- 
nection record is built (or updated) whenever a VMTP-like 
transport message is received. The advantage is that an 
explicit connection request is not required. The disadvantage 
is that longer and more carefully selected sequence numbers 
are required. A VMTP-like connection is half-duplex. (A 
full-duplex connection at a higher layer can be built with two 
independent half-duplex VMTP-like connections.) 
Acknowledgments must be handled by higher layers. 

Transport coimections are defined by the network end-to- 
end destin agon^ d.source addresses. 

f ^A^^ljg^^^ MEE^eout is associated with transport 
connections. Transport connection records are purged after a 
^M^C.'CP JLIFE time expires without activity on the con- 
nectibnTTlie transport entity in a terminal can ensure that its 
transport connection will not be lost by transnuuing- an 
empty time-fill transport packet whenev^ |EBMiIM EQUT 
time expires without activity. 

The transport entity in a node stores messages for possible 
retransmission. Note that retransmissions may not always 
follow the same path (primarily) due to moving terminals 
and the resulting changes in the spaiming tree. For example, 
the network entity in a parent node may disconnect a child 
after the DLC entity reports a message delivery failure. The 
child will soon discover that it is detached and will reattach 
to the spanning tree. Now when the transport entity (i.e. in 
the root) re-sends the message, it will follow Uie new path. 
Transport message timing and sleeping terminals. 

The transport entity in a terminal calculates a separate 
timeout for SEND and TRANSACTION operations. Ini- 
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tially, both timeouts are a function of the distance of the 
terminal from the root node. 

A TCP-like algorithm is used to estimate the expected 
propagation delay for each message type. Messages, which 
require a response, are retransmitted if twice the expected 5 
propagation time expires before a response is received. 
SLEEPING teraiinals can power down for a large percent- 
age of the expected propagation delay^beforc waking up to^ 

receive the resnonse mesoaoc T^hT^p'^K^IF^miccpH 



MeSiiwa"Acciss"CoM3*(^^ theory and implementation 
notes. 

Access to the network communications channel is regu- 
lated in several ways: executing the full CSMA algorithm 
(see MAC layer above). The sender retransmits unacknowl- 
edged messages until a RETRY MAX count is exhausted. 

The retry time of the DLC must be relatively short so that 
lost nodes can be detected quickly. When the DLC layer 
reports a failure to deliver a message to the network layer, 
the network layer can 1) save messages for SLEEPING 
terminals for later attempts, or 2) DETACH the node from 
the spanning tree. Note that most lost nodes are due to 
moving terminals. 

The node identifier part of the DLC address is initially all 
O's for all nodes except the root node. The all O's address is 
used by a node to send and received data-link frames until 
a unique node identifier is passed to the DLC entity in the 
node. (The unique node identifier is obtained by the network 
entity.) 

Address resolution. 

Well-known names too are bound to network addresses in 
several ways: 

The network address and TRANSPORT ACCESS ID of a 
name server, contained in the root, is well-known by all 
nodes. 

A node can register a well-known name with the name 

server contained in the root node. 
A node can request the network access address of another 
application from the name server by using the well- 
known name of the application. 
Possible extensions. 

Base station-to-base station traflSc could also be routed 
through the controller if the back>yard learning algorithm 
included base station nodes. (Each base station would sim- 
ply have to remember which direction on its branch of the 45 
spanning tree to send data directed toward another base 
station.) 

The possibility of multiple conU-ollers is kept open by 
including a spanning-tree identifier in address fields. Each 
controller defines a unique spanning tree. A node can be in 50 
more than one spanning tree, with separate network state 
variables defined for each. 

Thus, the prefemed embodiment of the present invention 
describes an apparatus and a method of efficiently routing 
data through a network of intermediate base stations in a 55 
radio data communication system. 

In alternate embodiments of the present invention, the RF 
Networks contain multiple gateways. By including a system 
identifier in the address field of the nodes, it is possible to 
determine which nodes are connected to which networks. 60 

As is evident from the description that is provided above, 
the implementation of the present invention can vary greatly 
depending upon the desired goal of the user. However, the 
scope of the present invention is intended to cover all 
variations and substitutions which are and which may 65 
become apparent from the illustrative embodiment of the 
present invention that is provided above, and the scope of 
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the invention should be extended to the claimed invention 
and its equivalents. 

In addition, attached hereto in Appendix A is an index to 
the software subroutines of the software program found in 
Appendix B. The software in Appendix B is an embodiment 
of the present invention. 

What is claimed is: 

1. A multi-hop data communication network having wire- 
less communication capability comprising: 

a plurality of mobile terminals; 

a plurality of bridges, each of the plurality of bridges and 
each of the plurality of mobile terminals having a 
wireless transceiver and comprising a node in the 
network; 

said plurality of bridges dynamically create and revise 
communication pathways between any two nodes in the 
network; 

each of said plurality of bridges independently store and 
maintain local information that specifies how commu- 
nication packets received should flow through that 
bridge toward a destination node; 

said plurality of bridges, together, form a spanning tree 
which specifies the communication pathways in the 
multi-hop communication network; and 

each of said plurality of bridges adding to each commu- 
nication packet received the identity of a next node in 
a communication pathway to the destination node, 

2. The multi-hop data communication network of claim 1 
wherein, using a backward learning technique, each of said 
plurality of bridges independentiy create and maintain 
locally stored information to specify how communication 
traffic should flow through that bridge. 

3. The multi-hop data communication network of claim 2 
further comprising a host computer node. 

4. The multi-hop data communication network of claim 2 
further comprising a root node that functions as a focal point 
of the conmiunication network. 

5. The multi-hop data conmiunication network of claim 4 
wherein each of the plurality of mobile terminals comprising 
means for connecting to the root node through selected ones 
of said plurality of bridges. 

6. The multi-hop data communication network of claim 4 
wherein the plurality of mobile terminals further comprising 
means for connecting to the root node using a HELLO 
packet protocol. 

7. The multi-hop data communication network of claim 6 
wherein spread spectrum communication is used in the 
transceivers of said plurality of bridges and said plurality of 
mobile terminals. 

8. The multi-hop data communication network of claim 6 
wherein the plurality of mobile terminals further comprising 
means for automatically re-establishing connection to the 
root node upon detachment 

9. The multi-hop data communication network of claim 4 
wherein the plurality of mobile terminals and the root node 
further comprising means for arranging conununicaton path- 
ways to provide a minimum number of hops between the 
root node and the plurality of terminal nodes without over- 
loading the root node or any of the plurality of terminal 
nodes. 

10. A multi-hop data communication network having 
wireless communication capability for providing communi- 
cation pathways comprising: 

a first communication node; 

a mobile second communication node from which it is 
desired to transmit communication packets to the first 



05/14/2004, EAST version: 1.4.1 



5,504,746 



19 

communication node, said second communication node 
having a wireless transceiver; 

a plurality of intermediate communication nodes, each of 
the plurality of intermediate communication nodes hav- 
ing a wireless transceiver, and said plurality of inter- s 
mediate communication nodes, together, comprising 
means for forming communication pathways to relay 
the communication packets from the second commu- 
nication node to the first communication node; 

said mobile second communication node supplementing lo 
each communication packet with routing informadon 
to guide that communication packet to a selected one of 
said plurality of intermediate communication nodes in 
a communication pathway to the lirst communication 
node; 

upon receipt of a communication packet, each of said 
plurality of intermediate communication nodes supple- 
menting the communication packet with routing iiifor- 
mation to guide the communication packet to said first 
communication node if said first conununication node 
is with range, else to another of said intermediate nodes 
in a conununication pathway toward said first commu- 
nication node; and 

said intennediate conununication nodes dynamically 
arranging communication pathways to provide a mini- 
mum number of intermediate communication nodes 
needed to complete a conarauhication pathway between 
the first and second communication nodes without 
overloading any one intermediate conmiunication 
node. 

11. The multi-hop data communication network of claim 

10 wherein the plurality of intermediate communication 
nodes further comprising means for establishing connection 
between the first and second communication nodes using a 
HELLO packet protocol. 

12. The multi-hop data communication network of claim 35 

11 wherein the plurality of intermediate communication 
nodes further comprising means for automatically re-estab- 
lishing connection between the first and second communi- 
cation nodes upon detachment. 

13. In a multi-hop data conununication system having a 40 
mobile computer node and a plurality of communication 
nodes, a method for providing communication among the 
nodes comprising the steps of: 

(a) establishing a communication link in a network for a 
selected one of the plurality of communication nodes; 45 

(b) indicating from the communication node which has 
been linked to those of the remaining, unlinked com- 
munication nodes that a communication link has been 
established; 

(c) establishing a wireless communication link between 
the unlinked communication nodes which receive the 
indication and the linked communication node; 

(d) repeating steps (b) and (c) for each conununication 
node which has established a wireless communication 55 
link imtil all of the plurality of communication nodes 
have been wirelessly linked; and 

(e) selectively and wirelessly linking by a mobile com- 
puter node to ones of said linked conununication nodes 

as necessary to dynamically maintain communication 60 
connectivity with the network as said mobile computer 
node moves throughout the networic. 

14. In a multi-hop data comimunication system having 
wireless capability, a communication node, a mobile temii- 
nal node, and a plurality of intermediate communication 65 
nodes, a method for providing communication pathways 
among the nodes comprising the steps of: 
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(a) establishing for the communication node a wireless 
conununication link with at least one of the plurality of 
intennediate communication nodes; 

(b) indicating by each of the wirelessly linked interme- 
diate communication nodes that a communication link 
has been established and providing the hopping dis- 
tance of that link; 

(c) analyzing, by the intermediate communication nodes 
which receive the indication and by the mobile terminal 
node if it receives the indication, the indication to 
determine whether to establish a wireless communica- 
tion link with the intermediate communication node 
providing the indication, and, if the analysis so indi- 
cates, establishing the wireless conununication link; 

(d) branching to step (b) if the mobile terminal node has 
not been linked; and 

(e) requesting, by any of the communication nodes which 
become unlinked, a communication link and branching 
to step (b). 

15. In a multi-hop data communication system having a 
root node, a plurality of communication nodes, and a plu- 
rality of mobile terminal nodes, a method for providing and 
maintaining communication pathways among die nodes 
comprising the steps of: 

(a) indicating by the root node that communication links 
may be established; 

(b) analyzing, by the conununication nodes which receive 
the indication, the indication to determine whether to 
establish a communication link witii the root node 
providing the indication, and, if the analysis so indi- 
cates, establishing a wireless communication link; 

(c) indicating by each of the linked conmiunication nodes 
the hopping distance of the link to the root node; 

(d) analyzing, by the communication nodes which receive 
the indication, the indication lo determine whetiier to 
establish a communication link with the linked com- 
munication node providing the indication, and, if the 
analysis so indicates, establishing a wireless commu- 
nication link; 

(e) branching to step (c) until all intermediate communi- 
cation nodes have been linked; and 

(f) requesting, by any of the mobile terminal nodes a 
wireless communication link with a selected one of the 
linked intenmediate nodes. 

16. In a multi-hop data communication system having 
wireless commimication capability, a root node, a plurality 
of communication nodes, and a plurality of mobile tenninal 
nodes, a method for providing conununication pathways 
among the communication nodes comprising the steps of: 

(a) indicating by the root node a readiness to establish 
communication links; 

(b) establishing wireless communication links between 
the root node and the communication nodes receiving 
the indication; 

(c) indicating by each of the linked communication nodes 
the number of wireless conununication links which 
have been established and providing the hopping dis- 
tance of the wireless link to the root node; 

(d) analyzing, by the communication nodes which receive 
the indication from the linked conununication nodes, 
the indication to determine whether to establish a 
communication link with the linked communication 
node providing the indication, and, if the analysis so 
indicates, establishing a wireless communication link; 

(e) branching to step (c) until all conununication nodes 
have been linked; 
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(f) indicating by the linked communication nodes the 
hopping distance of the link to the root node; 

(g) analyzing, by the plurality of mobile terminal nodes, 
the indications which are received from the linked 
communication nodes to determine with which linked 
communication nodes to establish a communicadon 
link, and, each mobile terminal node establishing at 
least one wireless communication link; 

(h) requesting, by any of the plurality of mobile terminal 
nodes which become unlinked, a wireless communica- 
tion link and branching step (f); and . 

(i) requesting, by any communication node which 
becomes unlinked, a communication link and branch- 
ing to step (c). 

17. In a multi-hop data communication system having a 
plurality of communication nodes and a plurality of mobile 
terminal nodes, a method for providing communication 
pathways among the communication nodes comprising the 
steps of: 

(a) selecting one of the communication nodes to be a root 
node; 

(b) indicating by the root node that communication links 
may be established; 
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(c) establishing wireless conununication links between 
the root node and the communication nodes receiving 
the indication; 

(d) indicating by each of the linked communication nodes 
the hopping distance of the link to the root node; 

(e) analyzing, by the linked communication nodes which 
receive each indication from the linked communcation 
nodes, the indications to determine whether to replace 
the current communication link with a link to the 
communication node providing the indication, and, if 
the analysis so indicates, replacing the communication 
link; 

(f) analyzing, by the unlinked communication nodes 
which receive each indication from the linked com- 
muncation nodes, the indications to determine whether 
to establish a communication link with the communi- 
cation node providing the indication, and, if the analy- 
sis so indicates, establishing the wireless communica- 
tion link; 

(g) branching to step (c) until all communication nodes 
have been linked. 
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